home *** CD-ROM | disk | FTP | other *** search
ssssdddd2222((((4444)))) ssssdddd2222((((4444)))) NNNNAAAAMMMMEEEE sounddesigner2, sd2, sdII - Sound Designer II Audio File Format SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS ####iiiinnnncccclllluuuuddddeeee <<<<ddddmmmmeeeeddddiiiiaaaa////aaaauuuuddddiiiiooooffffiiiilllleeee....hhhh>>>> DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN The Audio File Library currently supports eight of the commonly found audio file formats, i.e., is able to recognize, read, and write sample data and header information to and from files in these formats. It is important not to confuse _s_a_m_p_l_e or _a_u_d_i_o _d_a_t_a _f_o_r_m_a_t_s with _f_i_l_e _f_o_r_m_a_t_s. The former refers to the bit-wise organization of the sound samples in the file, i.e., whether the format is 8-bit integer or 16-bit unsigned, etc. Audio file format refers to the structure of the _a_u_d_i_o _f_i_l_e _h_e_a_d_e_r, the chunk of on-disk data which preceeds the samples and which provides information about the file to the audio program. A single audio file format may support a large variety of sample formats. The Sound Designer II Audio File Format (sd2) was created by DigiDesign, Inc., as a replacement for their earier Sound Designer I format (not supported by the Audio File Library). Because it was developed for the Apple MacIntosh file system, this file format differs from all other currently supported audio file formats in that its representation on a UNIX file system varies depending on how the file is made available. All involve a data fork or file containing the binary sample data and a resource fork or file containing all information about the file and its format. Three representations are supported: AAAApppppppplllleeee SSSSiiiinnnngggglllleeee FFFFoooorrrrmmmmaaaatttt Resource and data forks are combined into a single file AAAApppppppplllleeee DDDDoooouuuubbbblllleeee FFFFoooorrrrmmmmaaaatttt Resource and data forks put into separate files; the data fork file carries the actual file name, and the resource fork file has (in most cases) a percent (%) character prepended to the filename XXXXiiiinnnneeeetttt ((((IIIIRRRRIIIISSSSSSSShhhhaaaarrrreeee)))) FFFFoooorrrrmmmmaaaatttt Resource and data forks put into separate files; the data fork file carries the actual file name, and the resource fork file is located in a subdirectory named ".HSResource". This is always subdirectory of the directory containing the data fork file. In addition, a third file named .HSAncillary contains additional "ancillary data" about every Apple file in the current directory. This file stores information about the file type and file creation dates, among other things. DDDDAAAATTTTAAAA FFFFOOOORRRRMMMMAAAATTTT SSSSPPPPEEEECCCCIIIIFFFFIIIICCCCAAAATTTTIIIIOOOONNNNSSSS SSSSaaaammmmpppplllleeee FFFFoooorrrrmmmmaaaattttssss:::: Two's complement integer only PPPPaaaaggggeeee 1111 ssssdddd2222((((4444)))) ssssdddd2222((((4444)))) SSSSaaaammmmpppplllleeee WWWWiiiiddddtttthhhhssss:::: 16-bit only BBBByyyytttteeee OOOOrrrrddddeeeerrrrssss:::: Bigendian only CCCChhhhaaaannnnnnnneeeellll CCCCoooouuuunnnnttttssss:::: 1 and 2 channels only CCCCoooommmmpppprrrreeeessssssssiiiioooonnnn FFFFoooorrrrmmmmaaaattttssss:::: None supported, and none in common usage FFFFIIIILLLLEEEE FFFFOOOORRRRMMMMAAAATTTT SSSSPPPPEEEECCCCIIIIFFFFIIIICCCCAAAATTTTIIIIOOOONNNNSSSS Sound Designer II files can contain large amounts of additional information. IIIInnnnssssttttrrrruuuummmmeeeennnntttt CCCCoooonnnnffffiiiigggguuuurrrraaaattttiiiioooonnnnssss:::: Maximum of 1 allowed. Any number of loops per inst. Insts are stored as a set of loops with no associated instparams. Loops are stored as a starting frame, an ending frame, a loop sense (forward or forward-backward) plus an index (set incrementally from 0 up) and a channel (currently set to 0). MMMMaaaarrrrkkkkeeeerrrrssss:::: Any number of markers is allowed. Unlike AAAAIIIIFFFFFFFF(3dm) and WWWWAAAAVVVVEEEE(3dm) files, there is no direct association between markers and loops. An application may choose to specify loop start and end points via the traditional AIFF-style method using mark id's (aaaaffffSSSSeeeettttLLLLooooooooppppSSSSttttaaaarrrrtttt(3dm), etc.) or via the newer aaaaffffSSSSeeeettttLLLLooooooooppppSSSSttttaaaarrrrttttFFFFrrrraaaammmmeeee(3dm) and related routines. In the former case, both the loops and the markers will be written out to the header; in the latter case, only the loops will be written out (unless other markers have been created). In addition, it is possible to associate both a name string and a comment string with each marker. The routines aaaaffffIIIInnnniiiittttMMMMaaaarrrrkkkkNNNNaaaammmmeeee(3dm) and aaaaffffIIIInnnniiiittttMMMMaaaarrrrkkkkCCCCoooommmmmmmmeeeennnntttt(3dm) will do this. Both the name and comment will be written into a text buffer with the format <marker name>: <marker comment>. MMMMiiiisssscccceeeellllllllaaaannnneeeeoooouuuussss CCCChhhhuuuunnnnkkkkssss:::: AAAAFFFF____MMMMIIIISSSSCCCC____CCCCOOOOMMMMMMMMEEEENNNNTTTT text comment string CCCCAAAAVVVVEEEEAAAATTTTSSSS Due to the nature of the file structure as described above, the Audio File Library must take extra steps to identify and read this format. Specifically, it must have the full pathname of the file available for the call to identify the file (if used) and the call to open it. The functions aaaaffffIIIIddddeeeennnnttttiiiiffffyyyyNNNNaaaammmmeeeeddddFFFFDDDD(3dm) and aaaaffffOOOOppppeeeennnnNNNNaaaammmmeeeeddddFFFFDDDD(3dm) exist for this purpose, as well as the usual aaaaffffOOOOppppeeeennnnFFFFiiiilllleeee(3dm) call. PPPPaaaaggggeeee 2222 ssssdddd2222((((4444)))) ssssdddd2222((((4444)))) The current version of the AF can read Sound Designer II files in any of the above-three file representations, but all newly created files will be written in Xinet representation only. Future releases of the AF may allow a choice. SSSSEEEEEEEE AAAALLLLSSSSOOOO afInitFileFormat(3dm), afGetFileFormat(3dm), afIntro(3dm), afIdentifyNamedFD(3dm) PPPPaaaaggggeeee 3333 
